Cross shard leader accountability protocol based on two phase atomic commit

Sharding blockchain is a technology designed to improve the performance and scalability of traditional blockchain systems. However, due to its design, communication between shards depends on shard leaders for transmitting information, while shard members are unable to detect communication activities between shards. Consequently, Byzantine nodes can act as shard leaders, engaging in malicious behaviors to disrupt message transmission. To address these issues, we propose the Cross shard leader accountability protocol (CSLAP), which is based on the two-phase atomic commit protocol (2PC). CSLAP employs byzantine broadcast/byzantine agreement (BB/BA) for Byzantine fault tolerance to generate cross-shard leader re-election certificates, thereby reducing the impact of shard leaders on inter-shard communication. It also uses Round-robin mechanism to facilitate leader re-election. Moreover, we demonstrate that CSLAP maintains the security and liveness of sharding transactions while providing lower communication latency. Finally, we conducted an experimental comparison between CSLAP and other cross-shard protocols. The results indicate that CSLAP exhibits superior performance in reducing communication latency.

A blockchain 1 is essentially a decentralized database.It is a new application mode of distributed data storage 2,3 , point-to-point transmission, consensus mechanisms, encryption algorithms and other computer technologies 4,5 .However, for blockchains to be more widely used, the transaction throughput must be improved, and the confirmation delay should be decreased.Sharding is one of the key methods for solving the blockchain scalability problem, and an increasing number of systems are implementing sharding blockchains 6,7 .The key idea behind this approach is to create groups of nodes (or shards) that process only a subset of all transactions and system states, relying on the classic Byzantine fault tolerance protocols (BFTs) to achieve intra-shard consensus.The main purpose of intra-shard consensus is to process transactions within a shard.Therefore, the design of a consensus algorithm within a shard plays a vital role in the efficiency of transaction processing.The consensus algorithm needs to be able to efficiently process transactions within a shard and coordinate with other shards to complete cross-shard transactions, and this process requires the consensus algorithm in the shard to have a high degree of reliability and security to ensure stable network operations.Additionally, some sharding blockchains use reference committees 8 , so intra-shard consensus is also used to confirm the committee membership list.These sharding blockchain systems achieve optimal performance and scalability because: (i) Nonconflicting transactions can be processed in parallel by multiple shards; and (ii) The system can scale by adding new shards.This separation of transaction processing across shards is not completely "clean"; a transaction may depend on data managed by multiple shards, requiring the extra step of cross-shard consensus among related shards.
Atomic commit protocols (such as the two-phase atomic commit protocol (2PC)) typically operate on all relevant shards to ensure that cross-shard transactions are accepted by all or none of the shards.
In the 2PC protocol 9 , communication between shards is crucial.The 2PC protocol consists of a preparation phase and a commit phase 9 .During the preparation phase, the shard runs an in-shard consensus algorithm to prove whether the transaction input is available.We call this the availability certificate (AC).To reduce the complexity of communication, shards often elect a leader to act as a representative for communicating with other shards.However, centralizing trust in one node can lead to malicious behaviour.We introduce cross-transaction censorship attacks in the sharding blockchain, where an attacker can attack the leader of a related shard in a transaction, such as the BFT initiator of each shard in a Chainspace 10 ; After the shard leader is attacked and becomes a malicious leader, that malicious leader normally participates in and executes the BFT consensus algorithm within the shard (such as the PBFT, HotStuff, or Marlin); however, when cross-shard transactions are involved, the AC needs to be generated and sent to the relevant shards, and the malicious leader will not send AC to other shards related to the transaction.If the other shards do not receive all AC, they cannot agree on every part of the transaction, and the transaction will be permanently delayed.Although the intra-BFT consensus within a shard does not affect its liveness and security, the loss of agreement activity between shards still compromises the overall activity of the sharding blockchain.An attack can be executed even if the Byzantine security assumption 11 is met, and this attack wastes system resources.
There are currently two critical cross-shard consensus methods: (i) client-led cross-shard consensus and (ii) shared-led cross-shard consensus 12 .An attack on this type of consensus suits the shard-led cross-shard consensus and does not require coordination from external entities.Based on our analysis of performance trade-offs and vulnerabilities related to cross-transaction censorship in current shard-led cross-shard protocols, we propose the CSLAP protocol.The CSLAP we propose is general and applicable to sharding blockchain systems that use shard-led cross-shard consensus, such as RapidChain 13 , which utilizes the process of a 2PC to achieve high performance and scalability.RapidChain also combines the 2PC process with other methods to resist crosstransaction censorship attacks to achieve a more efficient protocol.The CSLAP identifies malicious shard leader behaviour when it does not receive the information that would allow it to perform the conversion of malicious leaders between shards and shards in the 2PC 9 .In the case of malicious behaviour, replacing the malicious leader node is the quickest solution compared to other remedial actions.
We implemented the CSLAP prototype in the Go language and compared it with other cross-transaction censorship attack defence protocols.The results show that the delay of our protocol is lower.
This study makes the following main contributions: (i) Cross-transaction censorship attacks against a shardled cross-shard consensus protocol were studied.Then, we introduced the classic sharding blockchain protocol and the latest cross-transaction review attack defence protocol.(ii) A new CSLAP that integrates our proposed defences to achieve resilience against cross-transaction censorship attacks without compromising the 2PC protocol was designed.(iii) The Byzantine prototype was implemented, and its performance was evaluated on real distributed node sets.Then, it was compared with previous protocols such as the CSVC 14 and the CSVC in a flexible sharing blockchain protocol (FS_CSVC) 15 .The results showed that the latency of the CSLAP protocol was the lowest.

Related work
Among cross-shard blockchains, ELASTICO 16 was the first public, decentralized, shard-based blockchain system.In ELASTICO, each shard is responsible for verifying a set of transactions and reaching a consensus based on the practical Byzantine fault tolerance (PBFT) algorithm.Afterwards, the final shard verifies all of the transactions received from the shards and includes them in a global block, which is then broadcast to all of the nodes in the system and stored.In RapidChain 13 , clients no longer need to request asset proofs from each input committee.Instead, they only need to send the transaction to any committee, and then, the transaction is routed to the output committee through the inter-committee routing protocol.In the OmniLedger solution 17 , the client initiates a request to the input committee, expecting each input committee to provide proof of acceptance for its respective assets.If the client does not receive all of the asset proofs and does not unlock the command, it assumes that the shards are honest and will not fail.Eventually, all of the messages are received, and a BFT consensus is reached.OptChain 18 includes an optimal transaction placement strategy by learning past transaction patterns, while BrokerChain 19 divides the account state graph through Metis, reducing cross-shard transactions based on the account model.Both models aim to reduce the number of transactions across shards and maintain load balancing across shards by appropriately distributing transactions to shards.Chainspace 10 employs a shard-led cross-shard consensus protocol called SBAC, wherein the client submits a transaction to the input shard.Each shard internally executes a BFT protocol, which enables it to make a temporary determination regarding the local acceptance or termination of the transaction.Subsequently, the shard broadcasts its local decision (preaccept(T) or preabort(T)) to other shards through the BFT initiator.
The above protocol assumes that the final result of each shard is honest and that the shard leader is honestly sending the generated information to the relevant nodes during the cross-shard process.In general, a malicious node in a shard can change the leader by trying to switch protocols, but members in a shard are usually unaware of the information between shards.Pyramid 20 is a blockchain based on hierarchical sharding in which some nodes can store multiple shards and process cross-shard transactions involving those shards.Since nodes may be waiting for resources to be released during the block commit phase, system deadlocks can easily occur.PolyShard 21 applies coded computation to sharding for linear scalability and security.It splits data into coded shards, enabling parallel processing and recovery of damaged shards.Ren et al. 22 proposed root graph placement to identify the shards that are most suitable for transactions based on interactions between the most recent transactions and historical transaction s and designed two techniques to mitigate the impact of the remaining cross-shard transactions on the system performance.One technique parallelizes dependent transaction validation with atomic commit protocols, and the other incorporates atomic commit protocols.X-shard 23 is a cross-shard transaction scheme for blockchain systems that uses an optimistic strategy to handle low-latency multiple input multiple output (MIMO) cross-shard transactions.Transactions are assumed to be valid and only verified when they are about to be committed to the output shard.Cross-shard transactions are processed through a gateway account managed by the board.Each cross-shard transaction is broken down into multiple intra-shard subtransactions that transfer coins to the gateway account in the input shard.Input shards process sub-transactions in parallel without waiting for other shards.If cross-shard transaction verification fails, the transaction is rolled back to ensure atomicity.The above protocols can reduce the proportion of cross-shard transactions or improve the delay they cause through parallelization , transaction merging and other technical means.As 24 noted, most of the previous studies were based on smaller variants of 2PC for cross-shard transactions.
In the description of cross-shard consensus attacks for Byzcuit 25 , which was designed by Alberto et al., the attackers resist the replay attacks of both the shard-led and client-led cross-shard consensus protocols.For cross-transaction review attacks, after the output leader does not receive a relevant shard certificate, the secure cross-shard view-change protocol 14 (CSVC) proposed by Liu et al attempts to perform intra-shard consensus to generate a cross-shard view-change certificate to replace the view.However, the protocol's design cannot accurately detect malicious behaviour exhibited by the leader within its own shard or within an input shard.The process of re-inquiry by shard members can only ensure the normal execution of the protocol, which increases the burden in terms of delay, and malicious leadership styles cannot be accurately identified.Liu referenced and improved the cross-shard view-change protocol in a flexible sharding blockchain protocol 15 in 2023 (FS_CSVC).The two cross-preparation and cross-commit construction stages are used to generate cross-shard view-change certificates.This protocol incorporates the members processes by repeatedly asking for certificate information.However, the process of re-inquiry still exists, and the problems mentioned above still exist.
Therefore, this paper proposes the CSLAP, which reduces the query process and ensures that leaders' malicious behaviour is detected at every step, thus reducing latency and improving security across shared consensus.

System model
Transaction (tx) tx refers to an operation or event recorded and verified on the blockchain network.Transactions typically involve the transfer of data, assets, or value, which serve as the fundamental building blocks of a blockchain system.A transaction consists of multiple inputs and outputs: Inputs: These define the source of tx, which could be outputs from previous tx or other types of digital assets.
Outputs: These represent the destination of tx.

Honest shard
We assume that all of the shards in the protocol are honest.An honest shard means that the proportion of honest members within it meets the target security threshold determined by the shard's internal consensus algorithm.Additionally, the shard reorganization process does not impact the assumption of shard honesty.In a sharding environment, the input and output of a transaction can be in different shards.We refer to the shard that manages the input as the input shard ( shard in 1 ,..., shard in n ) and the shard that manages the output as the output shard ( shard out 1 ,..., shard out n ).Sometimes, if a transaction's partial input and output are in the same shard, that shard can simultaneously be both an input and an output shard.
We i n d i c at e t h a t T{(I 1 , ..., I x ) → (O 1 , ..., O y ), I x ∈ shard in x , O y ∈ shard out y } .F o r e x a m p l e , T{(I 1 , I 2 ) → (O 1 , O 2 , O 3 )} indicates a transaction with two inputs I 1 , I 2 and three outputs O 1 , O 2 , O 3 , including the input divided shard in 1 , shard in 2 and the output divided shard out 1 , shard out 2 , shard out 3 , shard in 1 and shard out 1 , which are the same shard; however, it is easier to describe the different shard identities during the protocol operation.

Node
Let R in ={r in 1 ,...,r in i ,...,r in n } and R out = { r out 1 ,r out 2 ...,r out i ,...,r out n } be the set of n nodes in shard in and shard out .Each node r out i or r in i has a key pair ( sk i , pk i ) and is uniquely identified by its public key pk i in the system.We assume a public key infrastructure (PKI) that knows the public keys of all nodes to prevent identity spoofing.
In this system, nodes are classified based on their behaviour towards the protocol as follows: Honest nodes: These nodes adhere to the protocol, following the predefined rules and processes with integrity.Honest nodes ensure the system's reliability by conducting operations transparently and without deviation.
Malicious nodes: These nodes deviate from the protocol, engaging in behaviours that contradict or undermine the established rules.Malicious nodes may attempt to manipulate the system for personal gain or to disrupt the consensus process.They represent a risk to the system's security and can cause inconsistency or data corruption.

Adversary model
An adversary can destroy f of n nodes per-shard, where n ≥ 2f + 1 and the remaining nodes are correct.Therefore, the number of honest nodes is greater than n/2 to ensure an honest majority within each shard.The adversary is static, i.e. it chooses a set of f nodes to destroy at the beginning of the protocol and cannot choose to destroy other nodes afterwards.

Quorum certificate
There is a group of voting signatures that form the node's quorum certificate (QC), and the QC is composed of the voting rights of nodes 1/2 or more in the shard.A QC serves as a crucial component in blockchain governance and consensus mechanisms, ensuring that an action or block has received sufficient approval from the participating nodes.It acts as a proof of majority support, validating the authenticity and consensus behind a decision or block addition.

Network model
We adopt a synchronous network model in which any message sent by an honest node at time t arrives at another node before time t + , where is the known network maximum delay.The opponent can pass the message delay to a known upper bound .

Security properties Definition 1 (Consistency) In sharding blockchains, honest members reach a consensus on a transaction and will not commit to two conflicting transactions.
Definition 2 (Liveness) For any valid tx submitted by a client, after a certain period, all relevant shards finally decide whether to execute accept(T) or abort(T).Definition 3 (Cross-shard transaction censorship attack) Let tx = T{(I 1 , ..., I x ) → (O 1 , ..., O y ) be a cross-shard transaction where I j (j ∈ [1, x]) ∈ shard in j .Let L j behave as the leader of shard in j .If L in j pretends to be honest in shard in j but does not transfer or send invalid AC between related shards, then L in j is judged to launch a cross- shard transaction censorship attack.
Figure 1 briefly shows an example of an attack across attempts at censorship, depicting various situations in the 2PC phase for a tx with two inputs and three outputs.
The two inputs also serve as outputs for receiving acceptance or rejection information from the set coordinator.Here, the output shard out 3 acts as the coordinator.After receiving AC from the input shards shard in 1 and shard in 2 , the blockchain system performs verification and sends acceptance or rejection information back to shard in 1 and shard in 2 .Table 1 shows the cross-censorship transaction attack behaviour in the 2PC phase.Preaccept(T) means that an input shard temporarily writes changes locally; preabort(T) indicates that the write failed.Lock refers to locking a specific related object of the transaction; accept(T) means that the coordinator has received confirmation of the transaction, while abort(T) means that the coordinator has sent information indicating that the transaction has been rejected.Inactivated refers to permanently confirming changes and releasing related resource information, and unlocked refers to unlocking resources and rolling back the local writes.

Performance metrics
The CSLAP protocol involves a performance metric (the delay between finding a maliciously behaving leader and switching to an honest leader): • Latency (ms): latency for submitting cross-shard transactions.
• Throughput (bytes/s): the number of bytes processed per second.

CSLAP:Cross shard leader accountability protocol Protocol overview
The CSLAP allows the coordinator shard Shard out to observe the malicious behaviour of Shard in 's leader.Sub- sequently, the CSLAP generates a shard Shard in through the consensus algorithm proof related to the leader's malicious behaviour and sends it to the members of Shard in .After the members of Shard in judge the authenticity of the cross-shard leader re-election quorum certificate (CSLAP-QC) sent by Shard out , the members of Shard in use the round-robin algorithm to replace the malicious leader.Here, we use the BFT protocol based on the two primitives, BB/BA.Using a BFT protocol based on the BB requires protection against malicious behaviour by

Primitives
Round-robin leader election 26 The round-robin approach allows nodes to elect a leader for each epoch.The round-robin algorithm takes the last block as input and outputs a random leader from all nodes excluding the last f and misbehaving leaders.

Byzantine broadcast
A Byzantine broadcast is a protocol that allows a certain node (called the sender) to consistently distribute a message among n intra-shard nodes, in which up to f nodes are Byzantine.
Definition 4 (Byzantine Broadcast 27 ) A Byzantine broadcast satisfies the following properties: • (Agreement) If two honest nodes commit values B and B ′ , respectively, then B = B ′ .
• (Termination) All honest replicas eventually commit and terminate.
• (Validity) If the designated sender is honest, then all honest nodes commit on the sender's value.

Byzantine agreement
The Byzantine agreement is a protocol that allows certain nonfaulty (honest) replicas to decide on the same intra-shard output, in which up to f nodes are Byzantine.
Definition 5 (Byzantine Agreement 27 ) The Byzantine agreement satisfies the following properties: • (Agreement) If two honest nodes commit values B and B ′ , respectively, then B = B ′ .
• (Termination) All honest replicas eventually commit and terminate.
• (Validity) If all honest replicas have the same input value, then all honest replicas commit on the value.
Definition 6 (Byzantine Fault Toleranc 28 ) The BFT is a pivotal algorithm in distributed computing systems that is designed to achieve consensus in networks in which some nodes may fail or act maliciously.The BFT addresses the challenge of ensuring that a distributed system continues to operate reliably and reaches consistent decisions even when a subset of nodes experiences faults or exhibits hostile behaviour.The BFT protocol provides the following properties.
• (Safety): Every two honest nodes do not commit different blocks at the same height.During the first voting phase, the nodes tentatively write changes locally, lock resources, and report their status to the coordinator.If the coordinator does not receive AC from a node, it assumes that the node's local writes failed and sends a rollback message to all of the nodes to ensure that any local changes are reversed and that the locks are released.If the coordinator receives AC from all of the nodes, it initiates the second commit phase and sends a commit message to all of the nodes so that they can permanently write the changes and unlock resources.
In the context of a sharding blockchain, the atomic commit protocol operates on shards (which make the local changes associated with the voting phase via an intra-shard consensus protocol such as the PBFT) rather than on individual nodes.
Definition 8 (Availability Certificate 9 ) In the 2PC protocol, AC is a crucial document generated by each input shard involved in a transaction.These certificates are produced at the end of the first phase of the transaction and indicate each shard's preliminary reaction to the transaction, namely, whether to accept (preaccept) or reject (preabort) the continuation of the transaction.

Concrete protocol
Based on the above primitives, we propose our CSLAP protocol.Table 2 provides a complete protocol flow.The following describes the detailed execution process of the agreement through a transaction:

2PC-prepare
This phase is the first phase of a standard cross-shard transaction (the 2PC-prepare phase).Initially, the client broadcasts the transaction tx to all of the shard members.Then, a shard that does not contain the relevant transaction information forwards the tx information to the relevant shard and discards the transaction tx.The shard retains the transaction tx containing the relevant transaction information.Shard members then run the intra-shard consensus algorithm to generate a transaction AC i and send it to each relevant input and output shard.The input shard shard in i is used to run the intra-consensus algorithm to generate the transaction AC i .After T BFT + , each relevant shared 1/2 member and leader should have received all AC i related to tx.
BFT protocol based on the BB As a coordinator shard shard out , if the AC of all input shard transactions are typically received, then shard out executes the second phase of 2PC.After the members of shard out receive all relevant AC, they broadcast the certificate information and start a timer.The timer is set to t0 + 2 , where t0 is the timestamp in the last AC accepted, indicating the time when the input shards sent AC.The shards wait for the leader to take action until it times out, and they perform a view-change protocol to replace the leader.If the AC i for an input shard is still not received, the leader L out of shard out votes and runs the BFT protocol based on the BB to generate a CSLAP-QC.
To submit a proposal, two rounds of voting are needed.R out collects f + 1 valid votes < m vote > and uses the collected votes to build a CSLAP-QC.
BFT protocol based on the BA As a coordinator shard out , if the AC for all input shards is typically received, shard out performs the 2PC-commit.
If the AC for an input shard is still not received, member r out in R out executes the BFT protocol based on the BA Table 2. Cross shard leader accountability.

CSLRE: cross-shard leader accountability protocol
Let L in and L out be the leaders of shard in and shard out , and let replica r in and r out be the members of shard in and shard out .
The CSLRE protocol executes the following: i. 2PC-prepare.Using the BFT algorithm, r in generate AC for the tx protocol.Then, L in sends AC to at least f + 1 nodes of shard out .
ii. BFT protocol based on the BB/BA.
The generation of CSLRE − QC relies on the BFT protocol.
(a) BFT protocol based on the BB.If L out of shard out has not received AC for a relevant input shard shard in or received an error AC, L out broadcasts the Cross-Shard Leader Re- election proposal.r out runs the BFT protocol based on the BB to generate CSLRE − QC .If R out of shard out still has not received the leader's proposal information after receiving AC for t0 + 2 (t0 is the timestamp of the last accepted AC), it runs the view-change protocol.
(b) BFT protocol based on the BA.If R out of shard out has not received AC for input shard shard in or received an error AC, R out proposes to generate CSLRE − QC to switch L in from among the R out .
R out runs the BFT protocol based on the BA to generate CSLRE − QC.
iii.CSLRE-QC transfer.r out sends the generated CSLRE − QC to all r in of shard in and turns on a timer for 2 .iv. Leader Re-election.r in , upon receiving CSLRE − QC , uses the round-robin approach to switch L in ′ after determining the authenticity of CSLRE − QC .Then, the new leader L in ′ resends AC. v. 2PC-commit.If shard out re-receives AC before 2 , the process proceeds to the 2PC-commit as normal; otherwise, it returns to the second step to continue execution. Vol.:(0123456789)

CSLAP-QC transfer
After generating the CSLAP-QC in shard shard out , R out sends the CSLAP-QC to all members in shard in i and starts a timer of 2 .R in i first verifies the CSLAP-QC signature; if the verification is passed, the members of shard in i agree that their leader L in i is a malicious leader, and L in i does not provide AC x to other shards.The members of shard in i initiate a round-robin operation to switch the leader.

Leader re-election
When the current leader L in i is found to be acting maliciously, nodes R in i use a round-robin algorithm to elect a new leader L in i ′ .The algorithm uses the latest block in the blockchain as input to select a new leader from all nodes but excludes up to f nodes that have exhibited malicious behaviour and have recently served as leaders.The new leader L in i ′ resends the AC i information before the block state defaults to show malicious leader behaviour.

2PC-commit
If shard out still does not receive the AC for shard in i before the 2 timer expires, then the leader replaced by shard in i is considered malicious.The CSLAP continues to execute until shard in i becomes an honest node.After receiving all of the certificate information, shard out puts the transaction on the chain once the verification is completed.Additionally, it sends the acceptance or rejection information to all of the relevant shards.

Security analysis
Lemma 1 (Consistency) If the BA/BB and 2PC of the BFT protocol are consistent, then this agreement is considered consistent.
Proof We assume that tx T{(I 1 , ..., I x )) → (O 1 , ..., O y )} , where Shard out c is the coordinator shard.The transaction is broadcast by the client to all shards, and the input shard shard in i needs to generate the corresponding AC.The intra-shard BFT consensus is used to generate AC, which satisfies consistency for all required certificate stages.At this point, shard in i locks the relevant I i and sends AC to the coordinator shard.AC contains both the preaccept and preabort signals.Shard out c includes the following cases: (i) If Shard out c receives preabort (T), the transaction is considered invalid.The coordinator shards execute BFT consensus and send abort(T) to all related shards, indicating that the transaction has failed.The input shard unlocks I i .During this process, message broadcasts are sent to all shard members, ensuring that the members are informed.If a leader fails to send messages honestly, Shard members can still use the round-robin protocol to replace the leader, which also satisfies consistency.Therefore, this process satisfies consistency.(ii) During the 2PC process, two conflicting transactions cannot be submitted simultaneously, ensuring that this protocol is immune to double-spending attacks.When Shard out c has received enough evidence indicating preaccept(T) for each shard, the transaction is considered valid.Shard out c reaches a consensus on the transaction through the BFT and broadcasts the message to all shards.The CSLAP ensures that the message is broadcast to all members of all shards, ensuring that all shards receive the message.At this point, all of the input and output shards reach a consensus regarding the final outcome of the transaction, satisfying consistency.(iii) If the leader of shard in i is compromised and fails to send AC to some members, Shard out c runs the BFT to generate the CSLAP-QC, which is transmitted to its sender within the specified time frame.After receiving the CSLAP-QC, the input shard members save the current state for the round-robin process, ensuring that the current state in the blockchain is consistent with the pre-round-robin state.The new leader rebroadcasts AC.At this point, shard in i rebroadcasts, while Shard out c has not received all the AC, leading to a consistent waiting state for the transaction tx.The round-robin protocol does not affect the consistency property.Hence, the sharding protocol does not conflict with public prefixes and shards.
When Shard out c sends the CSLAP-QC, a 2 timer is initiated.If the timer expires without receiving AC from shard in i , the CSLAP protocol is re-executed until the AC from shard in i is received.During this process, all shards are either consistent or in a waiting state, meeting the consistency requirement.Thus, the sharding system can maintain transaction consistency, proving the correctness of the protocol.

Lemma 2 (Liveness) For any valid transaction tx submitted by a client, after a certain period, all relevant shards finally decide to execute accept(T) or abort(T).
Proof Let us assume that the start moment occurs when a client's transaction request is sent to all input shards.The liveness parameters are related to the parameters of the BFT protocol.For the input to a transaction, the input shard takes T BFT time to generate AC and time to send AC to the relevant shard.During the 2PC-commit phase, shard out also needs T BFT time to commit the transaction.It takes T BFT + to provide feedback to the input shard and reach full agreement.Therefore, when the relevant leaders are honest and optimistic, the transaction confirmation parameter T liveness can be calculated as 3T BFT + 3 .
There are two cases of proof of liveness.

Part I:
The leaders of all relevant shards in a transaction are honest.First, assuming that the leaders of all relevant shards for a transaction tx are honest, the input shard generates the AC of tx i through the BFT algorithm.Then, the input shard leader sends AC to the relevant shard.In shard out , after receiving all AC related to tx in shard out , shard out runs the intra-shard consensus algorithm and submits tx to the block.
Part II: The leaders of some shards are dishonest.The second case occurs when some input shard leaders are malicious.Malicious leaders can censor transactions in three ways: (i) After receiving the tx value from the client during the 2PC-prepare phase, the leader of the input shard is withheld.(ii) The input shard generates AC through the BFT protocol, but the leader of the input shard does not send AC to shard out .(iii) The input shard generates AC through the BFT protocol, but the leader of the input shard sends a conflicting AC.
• Case i: The member of the input shard does not receive the 2PC preparation proposal within the time of receiving the transaction information tx and initiates the active view-change mechanism.• Case ii/iii: After shard out receives tx and waits for T BFT + time, the BB/BA protocol generates the CSLAP-QC and sends it to the input shard.The input shard executes the round-robin protocol to replace the leader.
In Case ii/iii, considering the best case, the input shard is replaced with an honest node after executing the round-robin protocol once, and AC is sent normally; then, the protocol execution time is T BFT + 2 .The transaction confirmation parameter is T liveness = 4T BFT + 4 .In the worst case, if the input shard executes k(k <= f − 1 ) round-robin iterations before replacing it with an honest node, the shard needs to wait for 2 every time CSLAP is re-executed.Therefore, the protocol execution time is k(T BFT + 2�) + 2� + 3T BFT , and the transaction confirmation parameter is T w−liveness = (k + 3)T BFT + 2(k + 1)� .If an adversary is able to disrupt the liveness of CSLAP, it must either disrupt the voting power in the network by more than 1/2 or disrupt the termination of the BFT protocol based on the BB/BA, which has only negligible probability.Thus, the sharding system can maintain transaction liveness, proving the protocols correctness.
Theorem 1 In the synchronous network model, assuming that multiple malicious behaviours exhibited by different shard leaders are detected by different shards in the shard blockchain, the leaders of all malicious shards are still replaced in T liveness .
Proof This protocol allows parallel processing of malicious leaders behaviour, assuming that in a transaction, the leader of an honest shard detects the malicious behaviour of one or more leaders of the related shards.Since generating a CSLAP-QC certificate does not involve proposing blocks or generating any sequence of actions, the leader can simultaneously propose the BFT for malicious behaviour on multiple shards.After the certificate is generated, the shard members send the certificate to the relevant shards.Therefore, regardless of whether several leaders exhibit malicious behaviour, they will be the current malicious leaders within T liveness .

Theorem 2 Starting with sending AC t0, the coordinator shard members detect the malicious behaviour of this shard within the maximum t0+2 time and initiate a view change to switch and replace the current leader.
Proof Assuming a transaction, after generating AC, the time when the shard leader sends AC is t0, and the leader sends AC to the f + 1 members of the coordinator shard at the same time.The time when the members start receiving AC is t.AC contains the t0 timestamp.The time at which the shared leader receives AC is t ′ , t0 ( t, t ′ ) t0 + .Assuming that the shard leader is honest, the shard members receive AC within t ′ + and t0+� < t ′ +� < t0 +2 .Assuming that the coordinator shard leader is malicious, the coordinator shard members will not receive the prepare information from the coordinator shard leader within t ′ + .If t t ′ , then t ′ +� < t+ < t0+2 ; if t < t ′ , then t+� < t ′ +� < t0+2 .

Time complexity
From the moment malicious behaviour is detected, if one round-robin is executed to replace the input shard with an honest node, then the protocol execution time is T BFT + δ , where δ represents the actual transmission delay in the network.In the worst-case scenario, if the input shard needs a total of k rounds of polling (where k <= f − 1 ) before switching to an honest leader, and if each time the CSLAP is re-executed, it must wait for the maximum message round-trip delay of 2 , then the time for k rounds of polling is k × (T BFT + 2�).
The final successful replacement takes T BFT + 2δ .Hence, the total execution time for the protocol is www.nature.com/scientificreports/ Regarding the time complexity of the BFT, considering the PBFT as an example, its asymptotic time complexity is O(n 2 × �) , where n is the number of members in a single shard.Therefore, the execution time complexity can be represented as O((k + 1) × (n 2 × �) + 2k × � + δ) .Given that k <= f − 1 and f <= n−1 2 , we have the following: Since 2δ is constant and 2k × is smaller than ( n−1 2 ) × (n 2 × �) , the time complexity can be understood as O(( n−1 2 ) × (n 2 × �)).In the best-case scenario, in which only one swap needs to be replaced with an honest leader, the time complexity is O(n 2 × �) .In the worst-case scenario, in which f − 1 swaps are needed, the time complexity is O(( n−1 2 ) × (n 2 × �)) .Thus, the overall asymptotic time complexity is O(n 3 × �).

Communication complexity
When the system executes the CSLAP, the honest leader needs to broadcast, and the broadcast is one-to-many; therefore, the communication complexity is n, which is the number of members in a shard.When no message is received, the communication complexity of executing a BFT round (using the PBFT as an example) is O(n 2 ) .
Then, the process of regenerating the certificate and sending it is a multicast process; thus, there are n members in the fragment broadcast, and the communication complexity is O(n 2 ) .Finally, if the other shards are polled, the communication complexity is 1.If k rounds are performed, then the total communication complexity is k(O(n 2 + n 2 + 1) = O(k * n 2 ) .As described in Sect."Time complexity", the best communication complexity is O(n 2 ) , and the worst communication complexity is O(n 3 ) .Therefore, the asymptotic time complexity is O(n 3 ).

Performance analysis
Table 3 shows a comparison of the protocols.Identifying malicious leadership represents whether a leader with malicious behaviour can be accurately identified for each cross-transaction censorship attack.
Figure 2 shows the implementation process of the CSVC protocol, Fig. 3 is the execution process of the CSLAP, and Fig. 4 is the execution process of FS_CSVC.(We only focus on the security and consistency of transactions (1)  between shards and do not consider the transaction consensus process within shards.)In the CSVC, after leader L out 1 of S out 1 discovers the malicious behaviour of S in 1 , it notifies the members first, and then, the members ask L in 1 of S in 1 .If L in 1 provides a message to the inquiring member of S out 1 , then the member broadcasts AC in S out 1 , and the shard leader continues to process tx in the normal 2PC protocol; if R out 1 does not receive AC from L in 1 within 2 , it provides L out 1 with an agreement message, which is included in the BFT-commit phase.L out 1 then runs the BFT algorithm to generate a cross-shard view change (CSVC-CC).Next, L out 1 sends the CSVC-CC to f + 1 members of S in1 , and S in 1 members attempt to switch after verifying the certificate.We regard the two consensus rounds as T BFT and use δ to denote the real-time delay when a node sends information to other nodes.Therefore, leader replacement requires T BFT + 2δ + 2�.
L out 1 sends vcs-prepare to the shard first, and R out 1 receives the vcs-prepare request L in 1 query.If no message is received, the shard signs vcs-prepare.L out 1 then constructs csv-commit after receiving 2f + 1 signatures and generates csvc − CC after collecting 2f + 1 , and the message is broadcast to all members of S in 1 to change the view.The time required for a leadership change is T BFT + δ + 2�.
FS_CSVC adopts two rounds of BFT consensus.L out 1 first sends CSVC-PREPARE to the inside of the shard, and R out 1 receives CSVC-PREPARE to ask L in 1 queries and signs CSVC-PREPARE if no message is received.L out 1 then constructs CSVC-COMMIT after receiving the 2f + 1 signature and generates the csvc − CC information after collecting 2f + 1 .Then, the information is sent to all members of S in 1 for a view change.The time required to replace the leader is T BFT + δ + 2�.
The CSLAP protocol uses S in 1 to send certificate information to at least f + 1 S out 1 to ensure that L in 1 's malicious behaviour can be determined without request, and S out 1 is sent to all members of S in 1 after the CSLAP-QC is generated.
At this time, all members have reached an agreement on the malicious behaviour of the leader so that the leader can be replaced directly through the round-robin protocol, and there is no need to change the view and internal state through a view change.Since the round-robin protocol directly replaces its own information, the time consumed is negligible.In this context, regardless of whether the BFT protocol is based on the BB or BA, the runtime is uniformly considered T BFT .The time required for the protocol to replace a malicious leader is T BFT + δ .Thus, T CSVC > T FS_CSVC > T CSLAP .

Implementation & evaluation
We seek to answer the following questions through this evaluation: • What is the system's performance for two different intra-shard BFT protocols and three cross-shard lead conversion protocols under conditions of varying transaction sizes, maximum delays, and shard counts?("Performance evaluation of the intra-shard and cross-shard lead conversion protocols") • What is the system's performance when running the conventional two-phase commit protocol under conditions with different numbers of transaction rounds?("Performance evaluation of the two-phase commit protocol") • What is the system's performance when, for example, executing multiple rounds of cross-shard transactions in the presence of a malicious leader in one of the input shards?("Performance evaluation in complex networks")

Experimental setup
We deployed our implementation on a cloud instance from the Alibaba Cloud 29 .We used an ecs.g7.8xlarge instance (32 vCPUs, 64 GB of memory, and 25 GB/s network bandwidth) in our Hangzhou data centre 30 .The instance operates on a dedicated network with a network latency of no more than 20 ms, runs Windows 11 as the operating system, and uses 100 GB of SSD storage.In our experiment, the main metrics were latency (quantified in seconds) and throughput (quantified in bytes processed per second).

Implementation
We implemented a two-stage atomic commit model under the standard synchronous model.Shards mainly use BFTs based on the BB prototype to synchronize HotStuff (SYNC) 31 and reputation-based state machine replication (RBSMR) 26 for certificate information generation and final transaction confirmation.We modified the core logic of SYNC and the RBSMR by adding a cross-shard transaction model to ensure that messages sent from other shards are recognized and processed within the chip.Shards use a 2PC to interact with each other.The CSVC, FS_CSVC and CSLAP are three cross-shard lead conversion protocols.For different cases, we use the following abbreviations: When the intra-shard consensus is SYNC, there are no cross-shard lead conversion protocols between shards.In short, for SYNC, when the CSVC is used in the 2PC, it is called SYNC-CSVC; when using FS_CSVC, it is called SYNC-FS; and when CSLAP is used, it is called SYNC-CSLAP.The same is true when the intra-shard consensus is the RBSMR.We used fmt to output content and log to record log information, and we utilized net/http to simulate each of the different nodes.Additionally, we used the sync package to achieve synchronization among multiple goroutines.Moreover, we have reused the intra-shard consensus operations from SYNC and the RBSMR.In our implementation, the transactions proposed by customers are all cross-shard transactions and are specific to Shard out 3 is the coordinator shard by default.Other shards submit AC to shard out 3 .The model only processes the next transaction after executing one transaction.All throughput and latency results are measured from clients of separate processes that run separately on the same virtual machine as the shard members.We ensured that the performance of sharding is not limited by the lack of transactions proposed by the client.The network topology of the system is shown in Fig. 5.

Performance evaluation of the intra-shard and cross-shard lead conversion protocols
We first evaluated the baseline latency of a single-round 2PC protocol with fault tolerance ( f = 1 ) in a syn- chronous setting with = 100 ms.The number of members in each shard m was set to 4. Initially, we fixed the number of shard members and varied the transaction sizes, considering nine different transaction sizes ranging from 400 to 2000 bytes.For each transaction, we compared the latency of two distinct intra-shard consensus protocols, a standard two-phase commit protocol and cross-shard lead conversion protocols in the presence of a malicious leader.Each data point represents the latency from when the client broadcasts the inter-shard transaction to when the transaction is confirmed.After the client broadcasts the transaction, different shards reach a consensus, lock the transaction, and provide AC to the coordinating shard.As shown in Fig. 6, under honest shard conditions, the latencies for SYNC and the RBSMR were 668 ms and 956 ms, respectively; with a malicious leader, the latencies for SYNC-CSVC and SYNC-FS were approximately 1600 ms, and for RBSMR-CSVC and RBSMR-FS, they were nearly 2000 ms, with this protocol exhibiting latencies of approximately 1000 ms and 1500 ms, respectively.The presence of a malicious leader significantly increases the execution time.As the transaction size increases, the latency tends to increase; this phenomenon mainly due to the increase in packet size and the extended data transmission time.
Next, we fixed the transaction size and maximum transmission delay and varied the number of shards from 4 to 8. As depicted in Fig. 7, with changes in the number of shard members, since both internal consensus protocols are synchronous network models, the time taken typically fluctuates with the number of nodes, where system fluctuations are essentially network fluctuations.
Furthermore, we fixed other variables and set the maximum network delay to 20, 35, 50, 75, 100, 200, and 500 ms.As illustrated in Fig. 8, at = 20 ms, the latency for SYNC was 188 ms, and the latencies for SYNC-CSVC, SYNC-FS, and SYNC-CSLAP were 400, 380, and 268 ms, respectively.At = 500 ms, the latencies for these protocols were 3174 ms for SYNC and 7761, 7600, and 5174 ms for SYNC-CSVC, SYNC-FS, and SYNC-CSLAP, respectively.Their multiples increased from 2.12, 2.02, and 1.42 to 2.44, 2.39, and 1.63, respectively.These results demonstrate that the smaller is, the shorter the execution time of the protocols, the lower the impact of , and the greater the impact of δ .As increases, both SYNC and the BFT-SMR have a fixed timer cost, leading to a significant increase in network latency.
Finally, we present the latency and throughput variations of the system during a round of transactions when the number of shards is 3, 5, and 7.The fixed transaction size in the system is 400 bytes, with set to 100 milliseconds, and each shard has 4 members.As shown in Fig. 9, when the number of shards is 3, the system's latency is consistent with the above figure.Moreover, as the number of shards increases, the latency fluctuation remains within the 10 ms range due to the synchronous network model, in which the system exhibits fixed latency behaviour during execution.Fig. 10 shows that when the number of shards is 3, the throughput of SYNC is 580 bytes/s, while those of SYNC-CSVC and SYNC-FS are 243 and 241 bytes/s, respectively.SYNC-CSLAP achieves 375 bytes/s.The throughput of the RBSMR is 426.744bytes/second, while those of the RBSMR-CSVC, RBSMR-FS, and RBSMR-CSLAP are 195, 200, and 267 bytes/s, respectively.We observe that the throughput of the RBSMR-CSLAP is 50% and 35% higher than that of the other two protocols.As the number of shards increases, there are no changes in latency or throughput, which is attributed to the synchronous network model since it causes the system to exhibit consistent latency behaviour during execution.
In summary, in our system environment, the regular latency for a 2PC based on two intra-shard consensus protocols ranges between 660 and 960 ms, and protocols requiring leader changes result in greater latencies.The execution time for both the CSVC and FS_CSVC is three times that of the standard 2PC protocol.However, for regular submissions, the protocol requires only 1.5 times the latency.Compared to the CSVC and FS-CSVC, this protocol offers a performance improvement of approximately 50%.

Performance evaluation of the two-phase commit protocol
Next, we evaluated the latency consumed by a normal 2PC.We believe that after executing a cross-shard transaction, we can continue to execute the next transaction.All nodes in the system are honest nodes and implement the agreement as soon as they receive the message.Therefore, this test assesses the time delay and throughput of the system in the honest case.Theoretically, a normal round of two-stage atomic commits needs to go through 3T BFT + 3δ .Since is set to 100 ms, the transaction size is 400.As shown in Sect."Performance evaluation of the   intra-shard and cross-shard lead conversion protocols", the SYNC latency is 660 ms, while the RBSMR latency is 970 ms (Fig. 9).Therefore, the sync throughput is 600 bytes/s, and the RBSMR is 410 bytes/s.We began to record the delay and throughput of the number of rounds executed (1, 5, 10, 20, 50, 100, and 200).Fig.11 shows that the delay consumed by the system execution process is relatively stable overall, and it has little effect on factors such as network delay.It can be seen from Fig. 12 that the initial throughput was close to the throughput limit, but with the operation of the system, the network fluctuated.As a result, the data remained at approximately 575 bytes/s and 400 bytes/s.

Performance evaluation in complex networks
Sections "Performance evaluation of the intra-shard and cross-shard lead conversion protocols" and "Performance evaluation of the two-phase commit protocol" illustrate the execution processes of the 2PC protocol under basic conditions.Next, we aim to measure the latency and throughput of the system when executing cross-shard lead conversion protocols in the presence of malicious nodes.We set Shard in 1 to contain 20 members, 9 of which were malicious.The other shards remained honest.These malicious nodes, once elected as leaders, may engage in withholding behaviours.We then evaluated the system's throughput and latency over 5, 10, and 20 rounds, as depicted in Figs. 13 and 14.
From a latency perspective, the system maintains the same delay for one round, as shown in Sect."Performance evaluation of the intra-shard and cross-shard lead conversion protocols", but the overall ratio of latency across 5 rounds slowly approaches similarity.For instance, SYNC-CSVC exhibited a latency of 1600 ms in one round, while SYNC-CSLAP exhibited a latency of 100 ms.After 20 rounds, the total elapsed time was 15234 ms and 14165 ms, respectively, with the performance improvement decreasing from 1.5 to approximately 1.07 times.Similar patterns are observed with other protocols.These results indicate that malicious behaviour affects the overall system latency and throughput.However, as the number of rounds increases, the throughput gradually increases and approaches the performance levels of the previous honest experiments.This improvement occurs because malicious leaders are identified and replaced promptly, with the only performance loss occurring during the replacement process.In protocols such as SYNC and the RBSMR, nodes identified with malicious behaviour are recorded and prevented from being re-elected as leaders.Our protocol demonstrates faster throughput recovery in the presence of malicious nodes; in scenarios with one round of malicious activity, the throughput is approximately 50% higher than that of the other two protocols, demonstrating less impact from malicious leadership.

Conclusion
We have defined a cross-shard transaction censorship attack, which threatens the liveness of shard-led cross-shard consensus protocols.This type of attack involves a malicious leader acting honestly within a shard but concealing information between shards.Additionally, the complexity of communication protocols between shards plays a significant role in the efficiency of consensus protocols.To address these issues, we propose the CSLAP, a lowlatency consensus protocol designed to resist cross-shard transaction censorship.
We implemented a prototype of the CSLAP and compared it with previous protocols, and the results show that the CSLAP not only resists cross-shard transaction censorship attacks but also has lower communication latency than other protocols.This design is intended to address malicious behaviour in cross-shard consensus, primarily ensuring trusted interactions between shards.Thus, the protocol can be applied to protocols using atomic commits for cross-shard communication.
This paper mainly focuses on identifying and replacing malicious leaders in cross-shard transactions, and it uses the synchronous network model.The message arrives at the maximum network propagation delay, and the network conditions in real life may not be ideal.Therefore, in the nonsynchronous network model, the honest node may be switched due to the timing of resending cross-shard leader-re-election certificates.Second, the BFT-SMR based on the BA cannot meet the safety and activity requirements when the majority of nodes are not honest 32 .The BB-based BFT-SMR cannot satisfy safety and activity requirements with constant rounds 33 .Although we have significantly reduced the time needed to replace malicious leaders, this process may require  multiple broadcasts and multicasts, increasing the complexity of inter-shard communication.Additionally, the leader replacement process might continue until an honest node is found.In rare cases, there might be consecutive malicious nodes, leading to a significant increase in delay.
In terms of potential impact and applications, our work provides new insights and solutions for the design and implementation of sharding blockchain systems.Our methods and findings can guide the design and development of future sharding blockchain systems, enhancing their security.

Future work
The experiments conducted in this paper focus on simulating the process of a single protocol.In future work, we aim to deploy this process in a complete sharding blockchain system or apply other mechanisms to ensure correct transaction confirmation even in the presence of multiple consecutive malicious leaders.We also plan to adapt the CSLAP protocol to a partially synchronous network model, enhancing its stability and reliability under varying network conditions.
Because this study primarily explores communication among malicious leaders and since the protocol only adds some additional measures during inter-shard communication without altering the fundamental process of cross-shard communication, the CSLAP may be compatible with most atomic commit protocols.In the future, we can integrate this protocol with other cross-shard communication technologies.
A potential challenge in adapting the CSLAP to different network models is managing latency variations.Strategies for addressing this issue might involve introducing adaptive timeouts that adjust based on observed network conditions.This approach would help maintain system stability even in unpredictable environments.
With respect to adversary models, we will explore mechanisms for detecting and mitigating attacks from highly adaptive adversaries, and techniques such as randomized protocol steps or frequent leader rotation could improve the system's resilience against targeted attacks.This research direction aims to increase the robustness and adaptability of the CSLAP in diverse blockchain applications.
Overall, these future research efforts will contribute to enhancing the versatility of the CSLAP and provide innovative solutions for developing resilient blockchain technologies.

Figure 6 .
Figure 6.Latency comparison of different transaction sizes.

Figure 7 .
Figure 7. Latency comparison of different numbers of shard members.

Figure 9 .
Figure 9.Time delay of different shard members.

Figure 11 .
Figure 11.Delay of the two-phase atom submission transaction argument.

Figure 12 .
Figure 12.Throughput of the two-phase atomic submission transaction argument.

Figure 13 .
Figure 13.Time delay of different trading rounds.

Table 1 .
Highlighted rows in the table represent correct executions of 2PC (i.e.without an attacker); other rows represent incorrect executions due to cross-transaction censorship attacks.The content of each row can be divided into two sub-lines; the first sub-line shows the protocol messages sent by the shard, and the second sub-line represents the local shard operations after sending these messages.The first two columns represent the state of the input shard against the transaction at the end of the first phase of 2PC.The last three columns represent the final state of the output shard for the transaction after the second phase of 2PC ends.For example, (line 2) Shard in 2 is meant to provide pre-accept(T); however, due to the leader's withholding behaviour, pre-accept(T) was not received by any input fragments during the second stage.This issue leads to honest deals being rejected, and if the transaction execution fails, all shard operations are rolled back.Definition 7 (Two-phase Atomic Commit Protocol 9 ) This protocol has two phases that are run by a coordinator.
• (Liveness): If a transaction is received by an honest node, then the transaction will eventually be included in every honest node's ledger.
. shard out runs the BFT protocol based on the BA to generate a CSLAP-QC.After two rounds of voting, R out collects f + 1 valid votes < m vote > and uses the collected votes to construct the CSLAP-QC.

Table 3 .
Comparison among the CSLAP and other protocols.